home *** CD-ROM | disk | FTP | other *** search
/ FishMarket 1.0 / FishMarket v1.0.iso / fishies / 476-500 / disk_500 / wiconify / wiconcalls.lzh / wIconCalls.doc < prev    next >
Text File  |  1991-04-19  |  36KB  |  845 lines

  1. OVERVIEW:
  2.  
  3. wIconCalls.c implements the programmer's interface to wIconify.  It allows
  4. programs to specify their own, unique icon imagery for their windows; to
  5. manipulate their icons in more complex ways; to obtain information about
  6. icons and the wIconify system; and to maintain icons that do not have
  7. windows associated with them.
  8.  
  9. wIconCalls should be compiled and linked with the program that uses the
  10. wIconify programmer's interface (eventually, in the future, this will
  11. become a shared library).  The interface uses message-passing to communicate
  12. with the wIconify process.  The machinery for these messages is hidden in
  13. the wIconCalls routines, so that the programmer will be virtually unaware
  14. that it even exists.  Be aware, however, that any of the wIconCalls routines
  15. may call the Wait() function (this may effect the Forbid() status, for example).
  16.  
  17.  
  18. WICONCALLS STRUCTURES AND ROUTINES:
  19.  
  20. wIconCalls follows a strict naming convention to help prevent name conflicts
  21. with the programs that use it.  Any global routine that is part of the
  22. wIconCalls package starts with the letter 'w'; for example, wSetIcon() and
  23. wIconOf().  The same goes for the structures and types defined by wIconCalls,
  24. although if the types are defined in terms of C pre-processor macros, the
  25. name will be in all upper-case letters, including the initial 'W'.
  26. Finally, any macros defined in the wIconCalls hearder file all begin with 
  27. 'WI_' to help prevent conflicts with macro names (this is a practice that
  28. more programs should get in the habit of doing).  There is one exception to
  29. this rule, which is the macro BIT(n) which produced an integer with a 1 in
  30. bit position  n  and zeros elsewhere (ie, it equals (1<<n)).
  31.  
  32. wIconCalls defines two major structures:  wIcon and wIconMessage.  These are
  33. declared in the file wIcon.h, which should be included into any module that
  34. will be using the wIconCalls interface.
  35.  
  36. The wIcon structure defines the setup for an icon (its imagery, flags,
  37. etc.), and is used by wIconify to create an icon, but it is not the icon
  38. itself; it is simply a template.  This is similar to the NewWindow structure
  39. of Intuition; it is not the window itself, only the definition of one.
  40. Intuition uses a NewWindow structure to create an actual Window structure.
  41.  
  42. In the same way, wIconify takes a wIcon template and creates an actual
  43. icon.  The icon structure itself is for internal use by wIconify, and you are
  44. not given the definition of this structure (it may change in the future
  45. without notice).  When you create an icon, wIconify will give you an icon
  46. reference pointer, which you use to refer to the icon when you call
  47. wIconCalls routines.  wIcon.h declares a type WICONREF for these reference
  48. pointers, and a type WICON that is equivalent to 'struct wIcon'.
  49.  
  50. For example, the following code fragment uses a static WICON structure to
  51. add an icon to a window, iconifies the window, and then requests that the
  52. icon be selected, deselcting any other selected icons.
  53.  
  54.     WICON MyIcon = { /* static definition of wIcon goes here */ };
  55.     WICONREF *IconRef;
  56.     struct Window *myWindow;
  57.  
  58.     /* create a window */
  59.     IconRef = wSetIcon(myWindow,MyIcon);
  60.     wIconify(myWindow);
  61.     wSelectIcon(IconRef,FALSE);
  62.  
  63. Most icons will be associated with windows, as in the example above.  In
  64. this case, wIconify maintains the icon itself and removes the icon
  65. automatically when the window is closed.  At this point the WICONREF for
  66. that icon will become invalid, and should NOT be used.  wIconify can not
  67. tell an invalid WICONREF from a valid one (any more than Intuition can tell
  68. a valie window pointer from an invalid one), so be sure not to use a WICONREF
  69. after its window is closed.
  70.  
  71. There are times, however, when you may want to have an icon with no window
  72. attached (as is the case for the wIconClock icon).  In this case, you have
  73. to ask wIconify to create and delete the icon for you through the wAddIcon()
  74. and wRemoveIcon() calls.  Be sure to remove every icon you add, or wIconify
  75. will be left with icons that will never be removed.  This will prevent the
  76. screens where they reside from being able to close.  As with window icons,
  77. once the icon has been removed, the WICONREF becomes invalid and should not
  78. be used.
  79.  
  80. The second structure defined in wIcon.h is the wIconMessage structure.  It
  81. is used as a means of communication from wIconify to your program, and in
  82. many ways is similar to IntuiMessages that Intuition sends to your windows. 
  83. You can ask that wIconify let you know about important events in the lives
  84. of your icons; for example, you can ask to be informed when an window
  85. becomes iconified, or when an icon is openned or closed, or when your icon
  86. becomes selected, or when it moves.  You can even find out about new screens
  87. being openned, and other global events.  These message come to you as
  88. wIconMessages and they are sent to you through the IconPort associated with
  89. your icon.  This process is discussed in more detail below.
  90.  
  91.  
  92. RECEIVING WICONMESSAGES:
  93.  
  94. One of the most powerful aspects of the wIconCalls interface is the wide
  95. range messages that you can receive from wIconify concerning the icons you
  96. set up.  These are described in the two previous sections.  To get any
  97. wIconMessages, however, you must provide wIconify with an IconPort where it
  98. can send the messages.  Each wIcon need not have its own port - you can use
  99. the same port for all the icons you create.
  100.  
  101. You select what kinds of messages you want to receive by setting the
  102. WI_REPORT flags for your icon.  Once your icon is attached to a window, or
  103. added to a screen, you can use the Exec's Wait() function to wait for a
  104. message from wIconify (a typical approach would be to Wait() for a message
  105. either from wIconify or from Intuition).
  106.  
  107. Once you receive a message, be sure to reply to it.  If the user asks
  108. wIconify to end (either through the END menu item or by issuing the wIconify
  109. command while wIconify is running), wIconify will not be able to end until
  110. all the wIconMessage it has sent out are returned to it.  If you fail to
  111. reply to a message, wIconify will never end!
  112.  
  113. You should not modify the contents of a wIconMessage, except when
  114. specifically instructed to, as in the WI_REPORTICONVERIFY message.
  115. The wIconMessage structure is discussed in detail in the section THE
  116. WICONMESSAGE STRUCTURE below.
  117.  
  118.  
  119. ICONS WITHOUT WINDOWS:
  120.  
  121. Another important feature of the wIconCalls library is its ability to
  122. provide icons that are not attached to any window.  For example, the
  123. wIconClock utility uses just such an icon.  These windowless icons will
  124. almost certainly require IconPorts, and it is for them that most of the
  125. wIconMessage types will be most useful.  For example, the WI_REPORTOPEN and
  126. WI_REPORTCLOSE calls are alsmost useless for icons with windows, but they
  127. may be extremely important for windowless icons.  For example, programs that
  128. modify the system, like DropCloth, could put a small icon on the Workbench
  129. screen; openning this icon could bring up the program's configuration
  130. requester.  Another example is wIconClock, which opens an icon on every
  131. screen simply for display purposes.
  132.  
  133. You can use wIconify as a more direct part of your program's user
  134. interface.  For instance, you could open a screen and ask wIconify to put up
  135. an icon for each of the major functions of you program.  Clicking on an
  136. icon would initiate its function.  In a sense, these icons would act as
  137. gadgets, but with the ability to be rearranged, and with a slightly
  138. different set of messages available for them.
  139.  
  140. When you add an icon to a window, wIconify will remove the icon
  141. automatically when the window closes; however, if you place an icon on a
  142. screen, you must be sure to delete it yourself.  wIconify will not allow a
  143. screen to close as long as there are icons open on it.  There are a number
  144. of message types that can help in this situation.  First, you can specify
  145. the WI_AUTOREMOVE flag for an icon, which indicates that wIconify can remove
  146. that icon automatically as a screen closes.  If you don't want to use this
  147. flag, you should probably request WI_REPORTSCREENCLOSE messages.  In this
  148. case, when the a program tries to close the screen, wIconify will inform you
  149. so that you can remove the icon yourself.  Once all the icons are removed,
  150. wIconify will let the screen close.  If you fail to remove your icon,
  151. however, wIconify will never let the screen close!
  152.  
  153.  
  154. SCREEN ICONS:
  155.  
  156. The screen icons are actually associated with the wIconify backdrop window
  157. for each screen.  If you attempt to iconify this window, the screen will be
  158. iconified.  If you request the pointer to the window associated to a screen
  159. icon, you will get a pointer to the wIconify backdrop window.  Thus it is
  160. possible to do all your icon work with just window pointers and never deal
  161. with the screen-specific calls.  They are provided for your convenience,
  162. however, and are usually just as easy to use; but you should be aware of
  163. this somewhat unusual arrangement.
  164.  
  165.  
  166. THE WICON STRUCTURE:
  167.  
  168. A wIcon has the following structure:
  169.  
  170. struct wIcon
  171. {
  172.    char *Name;
  173.    struct Image *Image;
  174.    struct Image *Select;
  175.    UWORD *Mask;
  176.    WORD x,y;
  177.    ULONG Flags;
  178.    ULONG Report;
  179.    struct MsgPort *IconPort;
  180. };
  181.  
  182. The fields are used as follows:
  183.  
  184.  
  185.   Name
  186.  
  187. This is a pointer to the string to use for the name that appears just below
  188. the icon.  If this field is NULL, then the wIconify will use the name of the
  189. window associated with the icon (if there is no window for this icon, then 
  190. the string '[no title]' will be used).  To have a blank name, this field
  191. should point to an empty string.  The name will be centered under the icon.
  192.  
  193.  
  194.   Image
  195.  
  196. This is a pointer to an Image structure that should be used for the icon's
  197. image when it is unselected.  The size of the image can be up to 78 by 32
  198. pixels, and can be as many bitplanes as the screen it should appear on.
  199. If this field is left NULL, the default image will be used.  The default
  200. image can be specified using the wIconify initialization file (the wIconify
  201. documentation for more details).
  202.  
  203.  
  204.   Select
  205.  
  206. This is a pointer to an Image structure that should be used for the icon's
  207. image when it is selected.  In general, it should be the same size as the
  208. one used for the Image.  If the field is left NULL, then an inverted version
  209. of the Image is used, unless the image is the default image and a default
  210. select image has been specified, in which case it is used instead.  You can
  211. specify a default select image in the wIconify initialization file.
  212.  
  213.  
  214.   Mask
  215.  
  216. This is a pointer to an array of UWORDS to use as a mask for the icon.  The
  217. mask should be the same size as either the Image or the Select image, if one
  218. is provided.  The mask is used when the icon is being dragged to a new
  219. location.  Only the image bits that correspond to 1's in the mask will be
  220. drawn while the icon is being moved.  The mask will also be used as a "hit
  221. mask" for the image it is associated with; that is, mouse clicks will only
  222. be counted if they are on a pixel that corresponds to a 1 bit in the mask.
  223. If no Select image is provided, the mask is used as a hit mask for both the
  224. Image and the Select image; if a Select image is provided, the mask is only
  225. in effect when the Select image is being displayed.
  226.  
  227.  
  228.   x,y
  229.  
  230. These fields give the initial position of the icon in pixels from the upper
  231. left-hand corner of the screen.  If the icon would fall outside the visable
  232. area of the screen, or would overlap some other icon, it will be moved to
  233. the nearest open position on the screen, unless the WI_LOCKED flag is
  234. specified.  If x and y are both 0, wIconify will place the icon at the first
  235. available open position at the bottom of the screen.
  236.  
  237.  
  238.   Flags
  239.  
  240. This field contains the flag bits that should be in effect for this icon. 
  241. They can be chosen from among the following:
  242.  
  243.     WI_CHANGEREFRESH    If this icon's window is a SMART_REFRESH window,
  244.                         change it to SIMPLE_REFRESH when iconified (this flag
  245.                         has no effect on screen icons)
  246.  
  247.     WI_LOCKED           Never change the location of this icon, no matter what
  248.  
  249.     WI_NOMOVE           The user can not drag this icon
  250.  
  251.     WI_NOORGANIZE       The CLEANUP or ORGANIZE menus won't move this icon
  252.  
  253.     WI_NOSAVEPOS        Don't remember the icon's position after it is openned,
  254.                         it will be placed at the first available location next
  255.                         time it is iconified
  256.  
  257.     WI_NOMULTISELECT    Don't allow any other icons selected when this one is
  258.  
  259.     WI_NOCLOSE          The CLOSE menu will not be available for this icon
  260.                         (this flag has no effect on screen icons)
  261.  
  262.     WI_NOICONIFY        Don't allow this icon's window to become iconified
  263.  
  264.     WI_AUTOREMOVE       Remove this icon automatically when the screen it
  265.                         is on closes (for icons with no windows attached)
  266.  
  267. The following flags, which determine where the icon will appear and which
  268. direction to look for an open position, are not yet implemented.  They appear
  269. here for future compatibility.
  270.  
  271.     WI_LTOP
  272.     WI_LBOTTOM
  273.     WI_RTOP
  274.     WI_RBOTTOM
  275.     WI_VERTICAL
  276.     WI_HORIZONTAL
  277.  
  278.  
  279. In addition to the flags set by the user, wIconify maintains the following
  280. two flags:
  281.  
  282.     WI_ICONIFIED        This icon is currently iconified
  283.  
  284.     WI_SELECTED         This icon is currently selected
  285.  
  286.  
  287. It is important to understand the difference between WI_LOCKED and WI_NOMOVE.
  288. WI_NOMOVE simply means that the user can not drag the icon; wIconify is
  289. still free to position the icon as it sees fit in order to make the screen
  290. as uncluttered as necessary (for example, it is allowed to move the icon if
  291. some other icon is already at the location it requests).  On the other hand,
  292. WI_LOCKED indicates that wIconify may not move the icon under any
  293. circumstances, and that the icon's x,y position is exactly what it should be.
  294. This means that even if some other icon is in the way, or even if the icon
  295. will appear off the edge of the screen, wIconify will not move it, and a
  296. position of 0,0 will not be turned into the first open position.  Of course,
  297. wIconify will still allow you to move the icon via calls to wMoveIcon().
  298.  
  299. The combination of WI_NOMOVE and WI_NOORGANIZE is nearly the same as
  300. WI_LOCKED, except that it give wIconify the option of resolving the
  301. icon-overlap and off-screen problems without letting the icon be moved
  302. around by the user, but WI_LOCKED is still available if you really want to
  303. prevent this.
  304.  
  305. If you specify the WI_CHANGEREFRESH flag, the icon's window will be converted
  306. to a SIMPLE_REFRESH window before it is sent to the back.  Be aware,
  307. however, that this means any data displayed in the window will be lost! 
  308. When the window becomes visible again, Intuition will refresh its frame, but
  309. you will have to redraw the contents of the window yourself.  You may need
  310. to request WI_REPORTRESTORE messages in order to accomplish this.  In this
  311. case, though, you might as well have used a SIMPLE_REFRESH window in the
  312. first place.  Use of the WI_CHANGEREFRESH flag is not recommended, but is
  313. available if you want to try to save memory.
  314.  
  315.  
  316.   Report
  317.  
  318. This field specifies what type of wIconMessages you want to receive
  319. for this icon.  The messages come via the IconPort field described below,
  320. and can be chosen from the following flags:
  321.  
  322.   WI_REPORTICONIFIED    Report when this icon's window is iconified
  323.  
  324.   WI_REPORTRESTORE      Report when this icon is restored (the icon is
  325.                         reomved frlom the screen and its window openned)
  326.  
  327.   WI_REPORTICONVERIFY   Don't iconify the window until this message is
  328.                         replied (see below for more details)
  329.  
  330.   WI_REPORTMOVED        Report when the icon is moved to a new location
  331.                         by the user
  332.  
  333.   WI_REPORTSELECT       Report when this icon becomes selected
  334.  
  335.   WI_REPORTUNSELECT     Report when this icon becomes unselected
  336.  
  337.   WI_REPORTPRESS        Report when this icon is clicked on by the mouse
  338.                         (this is different from WI_REPORTSELECT; see below)
  339.  
  340.   WI_REPORTRELEASE      Report when this icon is released after is has been
  341.                         pressed (for example, when it has been dragged to a
  342.                         new location)
  343.  
  344.   WI_REPORTOPEN         Report when the user double-clicks this icon or chooses
  345.                         the OPEN menu when it is selected.  This is for use
  346.                         mainly with icons that have no windows attached; see
  347.                         below.
  348.  
  349.   WI_REPORTCLOSE        Report when the user attempts to close this icon.
  350.                         This is for use mainly with icons that have no windows
  351.                         attached; see below.
  352.  
  353.   WI_REPORTAUTOREMOVE   Report when this icon is removed automatically by
  354.                         wIconify when its screen closes.
  355.  
  356. In addition to these reports that pertain to a specific icon, you can get
  357. messages about more global aspects of wIconify:
  358.  
  359.   WI_REPORTNEWSCREEN    Tell me when new screens appear.  This is for use
  360.                         with programs like wIconClock that want to put
  361.                         icons on every screen.
  362.  
  363.   WI_REPORTSCREENCLOSE  Tell me when the screen is trying to close.  This
  364.                         is to let icons that are not WI_AUTOREMOVE icons
  365.                         that it is time to get off this screen!
  366.  
  367.   WI_REPORTACTIVATE     Tell me when the wIconify window becomes active
  368.  
  369.   WI_REPORTINACTIVE     Tell me when the wIconify window becomes inactive
  370.  
  371.   WI_REPORTICONEND      Tell me when wIconify is trying to end.
  372.  
  373. There is one unimplemented flag, for future expansion:
  374.  
  375.   WI_REPORTDROP         Tell me when an icon is dropped on top of this one.
  376.                         (This is to implement things like the trash-can and
  377.                         drawer icons).
  378.  
  379. Note the difference between WI_REPORTRESTORE and WI_REPORTOPEN.  The former
  380. is a message indicating that the icon's window has been successfully
  381. restored and the icon removed from the screen.  The latter is a message that
  382. the user wants the icon to open, but wIconify is leaving the details up to
  383. you.  For example, wIconClock uses this message to switch between its
  384. different display modes. 
  385.  
  386. WI_REPORTRESTORE is only applicable to icons with attached windows, and the
  387. latter is mainly for icons without windows.  If an icon was the
  388. WI_REPORTOPEN flag set, wIconify will generate a WI_REPORTOPEN message
  389. whenever an attempt is made to restore the icon, including during a call to
  390. the wRestore() routine.  If you wish to do some processing before your
  391. window opens and you specify the WI_REPORTOPEN flag, when the message is
  392. received, do whatever you need to do, then be sure to change the report
  393. flags with wModifyReport() to remove WI_REPORTOPEN before you call wRestore()
  394. for the window.  If you don't do this, you will just get another
  395. WI_REPORTOPEN message and the window still won't be restored.  Usually, it
  396. is better just to use WI_REPORTRESTORE and do whatever you need to do then.
  397.  
  398. If you specify the WI_REPORTICONVERIFY flag, then when the user tries to
  399. iconify the window associated with your icon, you will receive the icon
  400. verify message.  wIconify will wait for you to reply to the message before
  401. it iconfies the window, giving you a chance for you to do whatever you need
  402. to do to the window to prepare it for iconification.  If everything is OK
  403. and you want to allow the window to become iconified, set the WI_ICONIFYOK
  404. flag in the wIconMessage Flags field.  If you decide that the window should
  405. NOT become iconified, clear this flag in the wIconMessage Flags field.  You
  406. must reply to the message in either case.
  407.  
  408. The distinction between WI_REPORTSELECT and WI_REPORTPRESS also is
  409. important.  The WI_REPORTSELECT message indicates that the icon has become
  410. selected.  This can happen in a number of ways:  the user can click it, it's
  411. window can become iconified, which usually selects the newly-created icon,
  412. or your program can call wSelectIcon to select it.  On the other hand,
  413. WI_REPORTPRESS indicates the the user has clicked the mouse over the icon. 
  414. This message will be reported even if the icon is already selected.
  415.  
  416. The WI_REPORTACTIVATE and WI_REPORTINACTIVE messages apply only to the
  417. wIconify backdrop window where the icon exits, not to all wIconify windows;
  418. that is, an icon will receive these messages only when it's backdrop window
  419. becomes active or inactive.  Similarly, the WI_REPORTSCREENCLOSE message only
  420. applies to the screen on which the icon is to be found.
  421.  
  422.  
  423.   IconPort
  424.  
  425. This is a pointer to a MsgPort (message port) that wIconify should use to
  426. send you the wIconMessages you have requested by the Report flags.  If the
  427. port is NULL, wIconify will not send you any messages regardless of the
  428. settings of the Report field.  An IconPort can be shared among many icons,
  429. so there is no need to make an individual port for each icon you create.
  430.  
  431.  
  432. THE WICONMESSAGE STRUCTURE:
  433.  
  434. The wIconMessage structure is used in two different ways:  first, it is the
  435. means by which wIconify communicates with your program (through the
  436. IconPorts of your icons), and second, it is the way the wIconCalls library
  437. communicates with wIconify, through a named message port.  Much of the
  438. wIconMessage structure is for use by the wIconCalls library, and will not be
  439. used directly by you, nor with that portion of the structure be explained here.
  440. When you receive a wIconMessage, you should not modify any of its fields,
  441. except as specifically instructed, nor should you rely on the contents of the
  442. Data field, which is not valid when part of messages from wIconify to you.
  443.  
  444. The wIconMessage structure is as follows:
  445.  
  446. struct wIconMessage
  447. {
  448.    struct Message Message;
  449.    struct Window *Window;
  450.    WICONREF *Icon;
  451.    ULONG Action;
  452.    ULONG Flags;
  453.    union
  454.    {
  455.       struct Window *Window;
  456.       struct Screen *Screen;
  457.       WSCREEN *wScreen;
  458.       struct {WORD x,y;} Position;
  459.       struct {UWORD Depth,Modes;} NewScreen;
  460.       struct {UWORD Maj,Min;} Version;
  461.       struct {UWORD ScreenType,SizeToFit;} OpenOn;
  462.       WICON *Icon;
  463.       APTR DataPtr;
  464.    } Data;
  465. };
  466.  
  467. The fields have the following meanings:
  468.  
  469.  
  470.   Message
  471.  
  472. This is an Exec Message structure that is used to link the message into the
  473. IconPort, and includes the information necessary for you to be able to reply
  474. to the message.  You should not need to use this field yourself.
  475.  
  476.  
  477.   Window
  478.  
  479. This is a pointer to the window associated with the icon.
  480.  
  481.  
  482.   Icon
  483.  
  484. This is a pointer to the icon which is being affected by the message (in
  485. case you are using a common IconPort for all your icons).  Note that this
  486. a is pointer to a WICONREF, not a pointer to a wIcon.
  487.  
  488.  
  489.   Action
  490.  
  491. This tells you what type of event you have received.  It will be one of the
  492. WI_REPORT flags described above.  [This field also has special values when
  493. used as a message directed to wIconify by the wIconCalls library; see the
  494. wIcon.h include file for a list of these values.]
  495.  
  496.  
  497.   Flags
  498.  
  499. This field is used by wIconify to maintain information about the message. 
  500. The only value of interest to icon reports is WI_ICONIFYOK.  If you
  501. receive a WI_REPORTICONVERIFY message, you must set or clear this flag
  502. depending on whether you want wIconify to go ahead any iconify the window in
  503. question.  If the window should be iconified, set the flag, otherwise clear
  504. it.  Be sure that you do not alter the values of the other flags, as they
  505. are used by wIconify and the wIconCalls library.  [There are anumber of
  506. additional flags for internal use only; they are listed in the wIcon.h file.]
  507.  
  508.   union Data
  509.  
  510. This field is for internal use only, and should not be altered or used in
  511. any way by your program.  The values are all initialized and maintained by
  512. the wIconCalls library.
  513.  
  514.  
  515. WICONCALLS ROUTINES:
  516.  
  517. The routines below are part of the file wIconCalls.c which you should
  518. compile and link with your programs that want to use the wIconify
  519. programmer's interface.  Each of thr routines listed here indicates the type
  520. of its return value and the types of each of its arguments.  In most cases,
  521. NULL pointers will not cause a problem (wIconify will simply ignore the
  522. call, or provide a default when appropriate), so it's OK to use
  523. constructions like wIconify(wWindowOf(myIcon)) even though wWindowOf() may
  524. return NULL; the wIconify() routine is smart enough to check that the window
  525. pointer it gets is non-NULL.
  526.  
  527. The wIconCalls library communicates via wIconMessages with the wIconify
  528. handler process itself.  Since the wIconify process can end at any time (by
  529. the user selecting the END menu item, for example), this can be a tricky
  530. business.  For example, wIconify can be ended and restarted between two
  531. calls by your program to the wIconCalls library, and this would invalidate
  532. all your WICONREF pointers!  
  533.  
  534. In order to overcome at least some of the problems presented by this type of
  535. communication, wIconCalls checks to see that the same wIconify is running
  536. each time you make a call to the wIconCalls library.  If wIconify is no
  537. longer running, or if a different copy of it is running, then all subsequent
  538. calls to the wIconCalls library will return NULL or 0 values.
  539.  
  540. The wIconCalls library also checks the version of wIconify when it first
  541. makes contact.  Both wIconCalls and wIconify must agree that their versions
  542. match before any additional communication will be allowed.  If the versions
  543. don't match, all further calls to the wIconCalls library will return NULL
  544. or 0 values.
  545.  
  546. The routines available in the wIconCalls library are the following:
  547.  
  548.  
  549. int wIconifyActive()
  550.  
  551. This routine checks to see if wIconify is currently running.  It returns
  552. TRUE if wIconify is active and of a compatible version, and FALSE otherwise.
  553. You can use this routine to check to see whether your program should try to
  554. add icons to its windows, etc.
  555.  
  556.  
  557. WICONREF *wIconify(theWindow)
  558. struct Window *theWindow;
  559.  
  560. This routine attempts to iconify the specified window.  If successful, it
  561. will return the WICONREF for the icon of that window (wIconify will create
  562. one if the window does not already have one), and will return NULL
  563. otherwise.  The icon will appear on the same screen as the window, and will
  564. be selected if the window was the active one.
  565.  
  566.  
  567. WICONREF *wIconifyScreen(theScreen)
  568. struct Screen *theScreen;
  569.  
  570. This routine attempts to iconify the given screen.  If successful, it will
  571. return the WICONREF of the scren's icon, and will return NULL otherwise.
  572. The icon will appear on the Workbench screen, and will be selected if the
  573. active window was on the specified screen.
  574.  
  575.  
  576. void wRestore(theIcon)
  577. WICONREF *theIcon;
  578.  
  579. This routine attempts to restore the window of an iconfied icon.  The window
  580. will be brought to the front and activated, and the icon will be removed
  581. from the screen (but will still be associated with the window).  Calling
  582. this routine has the same effect as the user selecting the icon an choosing
  583. OPEN from the ICON menu.
  584.  
  585.  
  586. WICONREF *wSetIcon(theWindow,theIcon)
  587. struct Window *theWindow;
  588. WICON *theIcon;
  589.  
  590. This routine associates an icon with a window.  If successful, the routine
  591. will return a WICONREF pointer, and if unsuccessful (e.g., not enough
  592. memory) will return NULL.  The WICONREF pointer is what you will need to use
  593. to refer to the icon in most of the remaining wIconCalls routines.  The
  594. WICON itself is only a template used by wSetIcon() to create the WICONREF
  595. itself; any changes you make to theIcon after the call to wSetIcon will not
  596. affect the window's icon.
  597.  
  598. This routine DOES NOT iconify the window; it only associates the icon with
  599. the window so that when the window is iconified, it will have the right
  600. imagery, flags, position, etc.  If the window alreay has an icon, this
  601. routine will update the values of the existing icon.
  602.  
  603.  
  604. WICONREF *wSetScreenIcon(theScreen,theIcon)
  605. struct Screen *theScreen;
  606. WICON *theIcon;
  607.  
  608. This routine associates an icon with a screen.  If successful, it will
  609. return a WICONREF pointer, otherwise it returns NULL.  See wSetIcon() above
  610. form more details about WICONREFs and creating icons.
  611.  
  612.  
  613. void wUnSetIcon(theWindow)
  614. struct Window *theWindow;
  615.  
  616. This removes the icon associated with a window.  If the window is iconified
  617. in the future, wIconify will create a new icon for it, and will give it the
  618. default icon imagery and flags.  If the window has no icon, this routine
  619. has no effect.  If the window is iconified, it will be restored first.
  620.  
  621.  
  622. void wUnSetScreenIcon(theScreen)
  623. struct Screen *theScreen;
  624.  
  625. This removes the icon associated with a screen.  If the screen is iconified
  626. in the future, wIconify will create a new icon for it, and will give it the
  627. default icon imagery and flags.  If the screen has no icon, this routine
  628. has no effect.  If the screen is iconified, it will be restored first.
  629.  
  630.  
  631. void wUpdateIcon(theIcon,WIcon)
  632. WICONREF *theIcon;
  633. WICON *WIcon;
  634.  
  635. This routine updates the values of the WICONREF to those specified in the
  636. wIcon.  This is equivalent to unsetting the icon then setting it again.
  637. This routine is especially useful when used in conjunction with
  638. wGetIconData().
  639.  
  640.  
  641. void wGetIconData(theIcon,theIconRef)
  642. WICON *theIcon;
  643. WICONREF *theIconRef;
  644.  
  645. This routine copies the data from the WICONREF into the wIcon structure. 
  646. This gives you a "snap shot" of the current status of the icon.  You can use
  647. this in conjuntion with wUpdateIcon() to modify an icon's values.
  648.  
  649.  
  650. void wIconXY(theIcon,X,Y)
  651. WICONREF *theIcon;
  652. WORD *X,*Y;
  653.  
  654. This routine sets the X and Y variables to the current location (in pixels
  655. from the upper left-hand corner of the screen) of the specified icon.  You
  656. can modify the icon's location using the wMoveIcon() routine.
  657.  
  658.  
  659. ULONG wIconFlags(theIcon)
  660. WICONREF *theIcon;
  661.  
  662. This routine returns the current settings of the Icon's Flags field.  This
  663. can be used to check the WI_SELECTED or WI_ICONIFIED flags, for instance. 
  664. Use the wModifyFlags() routie to change the settings of the user-assigned
  665. flags.
  666.  
  667. ULONG wIconReport(theIcon)
  668. WICONREF *theIcon;
  669.  
  670. This routine returns the current settings of the icon's Report flags.
  671. Use wModifyReport() to change the flags.
  672.  
  673.  
  674. void wModifyFlags(theIcon,Flags)
  675. WICONREF *theIcon;
  676. ULONG Flags;
  677.  
  678. This routine sets the icon's Flags field to the given flags.  Only the user-
  679. assignable flags will be modified; any system flags will remain unchanged
  680. regardless of their presence or absence in the Flags parameter.  Use
  681. wIconFlags() to retrieve the current settings of the flags.
  682.  
  683.  
  684. void wModifyReport(theIcon,Report)
  685. WICONREF *theIcon;
  686. ULONG Report;
  687.  
  688. This routine sets the icon's Report flags to the requested values.  Use
  689. wIconREport() to retrieve the current settings of the Report flags.
  690.  
  691.  
  692. void wMoveIcon(theIcon,x,y)
  693. WICONREF *theIcon;
  694. WORD x,y;
  695.  
  696. Thie routine moves the specified icon to the specified location.  The x
  697. and y values represent pixels from the upper left-hand corner of the screen.
  698. Use wIconXY() to find the current location of the icon.
  699.  
  700.  
  701. void wSelectIcon(theIcon,AddToSelect)
  702. WICONREF *theIcon;
  703. long AddToSelect;
  704.  
  705. This routine attempts to select the given icon.  If AddToSelect is TRUE,
  706. then it will be added to the current list of selected icons; if AddToSelect
  707. is FALSE, then any selected icons will become unselected first.
  708.  
  709.  
  710. void wUnSelectIcon(theIcon)
  711. WICONREF *theIcon;
  712.  
  713. This routine unselects the specified icon.  If it was not selected, then
  714. this routine will have no effect.
  715.  
  716.  
  717. WICONREF *wAddIcon(theScreen,theIcon)
  718. struct Screen *theScreen;
  719. WICON *theIcon;
  720.  
  721. This routine attempts to add an icon without an associated window to the given
  722. screen.  If successful, it returns a WICONREF pointer to the newly-created
  723. icon, otherwise it returns NULL.  Since this icon will not have a window,
  724. wIconify will not be able to take any action when the icon is doubel
  725. clicked, or openned or closed; you should provide these icons with IconPorts
  726. so that wIconify can inform you of these events so that your program can
  727. take appropriate action.  See ICONS WITHOUT WINDOWS above for information
  728. about icons with no associated windows.
  729.  
  730.  
  731. void wRemoveIcon(theIcon)
  732. WICONREF *theIcon;
  733.  
  734. This routine removes an icon created by wAddIcon().  You must be sure to
  735. remove any icons that you add to a screen, otherwise the screen will not be
  736. able to close.  See ICONS WITHOUT WINDOWS above for more information.
  737.  
  738.  
  739. void wCloseIcon(theIcon)
  740. WICONREF *theIcon;
  741.  
  742. This routine attempts to close the given icon.  This may send a CLOSEWINDOW
  743. message to its associated window, or may send a WI_REPORTCLOSE message to
  744. the icon.  If the icon haas the WI_NOCLOSE flag set, this routine will have
  745. no effect.  Calling this routine is the same as the user selecting the icon
  746. and choosing the CLOSE item from the ICON menu.
  747.  
  748.  
  749. void wRefreshIcon(theIcon)
  750. WICONREF *theIcon;
  751.  
  752. This causes the given icon to be redrawn (actually, all the icons on the
  753. icon's screen will be redrawn).
  754.  
  755.  
  756. void wNoIconify(theWindow)
  757. struct Window *theWindow;
  758.  
  759. This routine marks a window as being un-iconifiable.  Any attempt to iconify
  760. the window will fail.  To make the window iconifyable again, you must call
  761. the wUnSetIcon() routine.
  762.  
  763.  
  764. int wIsIconified(theWindow)
  765. struct Window *theWindow;
  766.  
  767. This routine checks to see if a given window is currently iconified.  It
  768. returns TRUE if it is iconified, and FALSE of not.
  769.  
  770.  
  771. int wIsScreenIconified(theScreen)
  772. struct Screen *theScreen;
  773.  
  774. This routine checks to see if a given screen is currently iconified.  It
  775. returns TRUE if it is iconified, and FALSE if not.
  776.  
  777.  
  778. WICONREF *wIconOf(theWindow)
  779. struct Window *theWindow;
  780.  
  781. This routine returns the WICONREF pointer for the icon associated with the
  782. given window.  If the window has no icon, it returns NULL.
  783.  
  784.  
  785. WICONREF *wIconOfScreen(theScreen)
  786. struct Screen *theScreen;
  787.  
  788. This routine returns the WICONREF pointer for the icon associated with the
  789. given screen.  All screens are given default icon definitions when they are
  790. openned, so it will return NULL only if the screen is one of the ones marked
  791. to be ignored (via the IGNORE_SCREEN command of the wIconify initialization
  792. file; see the wIconify documentation for more details).
  793.  
  794.  
  795. struct Window *wWindowOf(theIcon)
  796. WICONREF *theIcon;
  797.  
  798. This routine returns a pointer to the window associated with the given
  799. icon.  If the icon has no window, it returns NULL.  If the icon is a screen
  800. icon, it returns a pointer to the wIconify backdrop window for that screen.
  801.  
  802.  
  803. struct Window *wBackDropOf(theScreen)
  804. struct Screen *theScreen;
  805.  
  806. This routine returns a pointer to the wiconify backdrop window of the given
  807. screen.  If the screen is one that wIconify is ignoring, this will return
  808. NULL.  You should not really be messing with the backdrop window, but
  809. sometimes you may need to find something out about its size or fonts, or
  810. something.  You should not draw into this window yourself, or add gadgets or
  811. other imagery to it.
  812.  
  813.  
  814. THE FUTURE OF WICONCALLS:
  815.  
  816. Currently, wIconCalls is a single C source file that has to be linked into
  817. your programs directly.  It might be helpful to turn it into a shared
  818. library, just like Intuition.library, Graphics.library, etc.  The wIconCalls
  819. file is pretty small, though, so maybe this is not so important.  It will
  820. depend on the amount of demand there is for this feature.
  821.  
  822. There are a number of potential improvements for the interface, including
  823. some of the unimplemented flags discussed above.  In addition, it would be
  824. possible to allow programs to incorporate their own menus into the wIconify
  825. backdrop window's menu bar.  It might also be useful to allow programs to
  826. request that their own windows become icon windows (i.e, scrollable windows
  827. that contain icons, just like the Workbench disk and draw windows).  This
  828. would allow programs to take more advantage of the capabilities of the icon
  829. interface of wIconify.  Of course, unless there is some demand from the
  830. users of the wIconify programmer's interface, these things probably will
  831. never happen.
  832.  
  833.  
  834. AUTHOR:
  835.  
  836. wIconCalls
  837. Copyright (c) 1990,1991 by Davide P. Cervone, all rights reserved.
  838.  
  839. Davide P. Cervone
  840. Department of Mathematics
  841. Brown University
  842. Providence, Rhode Island  02912
  843. ST402523@BROWNVM.BITNET
  844. st402523@brownvm.brown.edu
  845.